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Requirements  Engineering  and 

Management 


•  What  is  Requirements  Engineering  and 
Management? 

-  A  collection  of  activities  undertaken  by  many  people 
on  a  project  in  order  to  gather,  document,  store, 
analyze,  track,  and  implement  requirements,  while 
controlling  change  and  communicating  with 
stakeholders. 

•  Why  do  we  need  Requirements 
Engineering  and  Management? 

-  People  involved  on  the  project  are: 

•  Continually  kept  apprised  of  requirement  status 

•  Understand  the  impact  of  changing  requirements 
specifically,  to  schedules,  functionality,  and  costs. 
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lOM 


Requirements  Engineering  and 

Management 


Ensures  that  the  voice  of  the  customer  is 
heard  throughout  the  entire  development 
process 

Not  restricted  to  a  single  phase  in  the  lifecycle 

Key  task  is  traceability  of  the  requirements 

Different  techniques,  approaches  and  tools 
may  be  used 

Success  depends  on  the  commitment  of  the 
whole  project  team 
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What  are  Requirements? 


Requirements  Define: 

•  What  the  users  want  to  achieve. 

•  What  the  system  must  do  to  satisfy  user 
needs. 

•  What  each  component  must  do,  and  how 
components  will  interact. 

Requirements: 

•  Have  only  one  "shall"  statement 

•  Have  only  one  action  verb 

•  Do  not  have  stacked  (multiple)  "shall" 
statements  in  a  list 
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What  should  a  Requirement 


•  Unambiguous  -  The  reader  of  a  requirement 
statement  should  be  able  to  draw  only  one 
interpretation  of  it. 

•  Verifiable  -  There  is  a  value  or  test  to  measure  the 
requirement  against  to  insure  the  intent  of  the 
requirement  is  being  met.  The  verification  methods  can 
be  an  inspection,  demonstration,  analysis,  or  a  test  to 
determine  whether  each  requirement  is  properly 
implemented  in  the  product. 

•  Traceable  -  You  should  be  able  to  link  each 
requirement  to  its  source,  which  could  be  a  higher-level 
system  requirement,  a  use  case,  or  a  voice-of-the- 
customer  statement 
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What  should  a  Requirement 

Be?  (Cont.) 


Correct  -  Must  accurately  describe  the  functionality  to 
be  delivered. 

Feasible  -  Must  be  possible  to  implement  each 
requirement  within  the  known  capabilities  and 
limitations  of  the  system  and  its  environment. 

Necessary  -  Should  document  something  the 
customers  really  need  or  something  that  is  required  for 
conformance  to  an  external  requirement,  an  external 
interface,  or  a  standard. 
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How  TARDEC  Manages 
Requirements 


DOORS  (Dynamic  Object-Oriented  Requirements 
System) 

-  Made  for  Requirements  Engineering  and  Management 

-  Traceability  (requirement,  derived  requirements, 
decisions,  test  reports,  etc.) 

-  Allocations 

-  History/Change  Management 

-  Baselining 

-  Access  Control 

-  Single  Access  Point  for  Requirements 

-  Able  to  Export/Import  Information  into  Other  Formats 
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DOORS  Training  Modules 


LCMC  managers  - 
indirect  consumers  of 
DOORS  data 

Direct  consumers  of 
DOORS  data 

Data  owners  and 
authors 

Power  users,  administrators, 
project  jump-start  teams 

Leveraging  DOORS 

2  hour-  concepts  only 

Intro  to  DOORS 

2  hour  hands-on  +  homework 

DOORS  Basic  User  Training 

2  hour  hands-on  +  homework 

DOORS  training  is  available 
through  TARDEC  SEG.  Contact 

Traceability  Links 

2  hour  hands-on  +  homework 

Importing  Information  into  DOORS 

4  hour  hands-on  +  homework 

any  SEG  group  member  for  more 
information. 

Managing  DOORS  Projects 

4  hour  hands-on  +  homework 

UNCLASSIFIED 

Decision  Management  in  DOORS 

4  hour  hands-on  +  homework 

DOORS  Extension  Language  (DXL} 

4  hour  hands-on  +  homework 

/ 


Benefits  of  Requirements  Engineering 
and  Management  using  DOORS 


X  U  \ 


Traceability  From  Highest  Level  Requirements  To  Implementations 

□  Established  Via  Links  In  DOORS  Database 

□  Building  Traceability  Improves  The  Quality  Of  Requirement 
Analysis,  Ultimately  Producing  Better  Work  Products 

Impact  Assessments  Of  Proposed  Changes 

□  DOORS  Analysis  Tools  Let  You  See  Which  Other  Requirements 
Will  Be  Affected  By  A  Change 

Controlled  Access  To  Project  Information 

□  A  Shared  Database  Ensures  That  All  Users  Are  Working  With 
Current  Data 

□  A  Central  Repository  Allows  Controlled  Access  To  Essential 
Information 

Change  Control 

□  DOORS  Complements  Configuration  Management 
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Leveraging  DOORS  at  TARDEC 


Ground  Systems  Integration  Domain  (GSID) 

1.  Support  Systems  Engineering  Analysis 

2.  Align  Capability,  Platform  and  Technology 
Roadmaps 

3.  Inform  S&T  Portfolio  Decisions 
S&T  and  AC  AT  Programs 


FOCs 

WFOs 


Capability 
Gaps  +  1-N 

5 


x 


Vehicle 

Platforms 


Solutions 

Portfolio 

i 


S&T 

Programs 


1.  Maintain  continuous  traceability  between  plans, 
decisions,  requirements,  designs  and  tests 

2.  Frame  and  inform  decisions  (trade  studies) 

3.  Guide  modeling,  simulation  and  prototyping 

4.  Manage  baselines 

5.  Adapt  quickly  to  changes  and  lessons  learned 


Knowledge  Reuse 


Plans 

SOW-WBS-SEP 


Decisions 


Architecture 


Requirements 


H 


Tests 


1.  Develop  and  refine  patterns  and  templates 
(decisions,  requirements,  plans) 

2.  Jump-start  programs;  accelerate  solutions 

3.  Identify  opportunities  for  common  solution 

A  lot  more  than  just  requirements .... 
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DOORS  Information  Model 
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Issues  can  be  linked 
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Requirements  Traceability 
Information 


Questions  traceability  can  answer 


SOW 

W  hat  is-  ou  r  scope 
&  charter? 


How  will  work  flow 
dow  nto  others? 


H  c  w  wi  1 1  we 
accomplish  our 
charter?  (Is  our  plan 
adequate? 


WBS 

W hat's  our  plan? 
Who's  res  pons  i  ble  ? 
Is  plan  adequate? 


N- Squared  Diagram  Legend 


Node  A 

A-tc-B 

interaction 

B-to-A 

hte  ractbn 

NodeB 

Read  the  interacton  s  cbckwise 


H  c  w  wi  1 1  we 
analyze  or 
implement  this 
decision? 


DECISIONS 
Top  N  de  dsions? 
Status?  Rationale? 
Consequences? 


W  hy  does  this 
component  east? 
W  hat  role  does  it 
play? 


Where  did  this 
requirement 
orginate? 
Chang  eimpact? 


ARC  HITECTURE 


C  omo  onents  in  our 
solution? 

Iln  terfaces? 


What  decisions  dii 
this  req't  drive? 
Budget  a  location? 
Change  impact? 


Allocated 
requirements? 
Budget  flow-d  own? 


REQUIREMENTS 

Success  =  ? 

Clea  r?  Com  pi  ete  ? 
Source? 


Requirements  per 
test? 

Verficatbn 

coverage? 


Require  me  nts  met? 
Priority  gaps  to  fix? 


TESTS 

"lest  eve  nta'c  a  s  es? 
"lest  enablers? 
Resufcs.Tindhgs? 
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